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Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2004). 
Abstract 


This memo gives a mission statement for the IETF, tries to define the 
terms used in the statement sufficiently to make the mission 
statement understandable and useful, argues why the IETF needs a 
mission statement, and tries to capture some of the debate that led 
to this point. 


1. Mission Statement 
The goal of the IETF is to make the Internet work better. 


The mission of the IETF is to produce high quality, relevant 
technical and engineering documents that influence the way people 
design, use, and manage the Internet in such a way as to make the 
Internet work better. These documents include protocol standards, 
best current practices, and informational documents of various kinds. 


The IETF will pursue this mission in adherence to the following 
cardinal principles: 


Open process - any interested person can participate in the work, 
know what is being decided, and make his or her voice heard on the 
issue. Part of this principle is our commitment to making our 
documents, our WG mailing lists, our attendance lists, and our 
meeting minutes publicly available on the Internet. 


Technical competence - the issues on which the IETF produces its 
documents are issues where the IETF has the competence needed to 
speak to them, and that the IETF is willing to listen to 
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technically competent input from any source. Technical competence 
also means that we expect IETF output to be designed to sound 
network engineering principles - this is also often referred to as 
"engineering quality". 


Volunteer Core - our participants and our leadership are people who 
come to the IETF because they want to do work that furthers the 
IETF’s mission of "making the Internet work better". 


Rough consensus and running code - We make standards based on the 
combined engineering judgement of our participants and our real- 
world experience in implementing and deploying our specifications. 


Protocol ownership - when the IETF takes ownership of a protocol or 
function, it accepts the responsibility for all aspects of the 
protocol, even though some aspects may rarely or never be seen on 
the Internet. Conversely, when the IETF is not responsible for a 
protocol or function, it does not attempt to exert control over 
it, even though it may at times touch or affect the Internet. 


2. Definition of Terms 


Mission: What an organization sets out to do. This is in contrast to 
its goal (which is what it hopes to achieve by fulfilling its 
mission), and to its activities (which is what specific actions it 
takes to achieve its mission). 


The Internet: A large, heterogeneous collection of interconnected 
systems that can be used for communication of many different types 
between any interested parties connected to it. The term includes 
both the "core Internet" (ISP networks) and "edge Internet" 
(corporate and private networks, often connected via firewalls, 
NAT boxes, application layer gateways and similar devices). The 
Internet is a truly global network, reaching into just about every 
country in the world. 

The IETF community wants the Internet to succeed because we 
believe that the existence of the Internet, and its influence on 
economics, communication, and education, will help us to builda 
better human society. 


Standard: As used here, the term describes a specification of a 
protocol, system behaviour or procedure that has a unique 
identifier, and where the IETF has agreed that "if you want to do 
this thing, this is the description of how to do it". It does not 
imply any attempt by the IETF to mandate its use, or any attempt 
to police its usage - only that "if you say that you are doing 
this according to this standard, do it this way". The benefit of 
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a standard to the Internet is in interoperability - that multiple 
products implementing a standard are able to work together in 
order to deliver valuable functions to the Internet’s users. 


Participants: Individuals who participate in the process are the 
fundamental unit of the IETF organization and the IETF’s work. 
The IETF has found that the process works best when focused around 
people, rather than around organizations, companies, governments 
or interest groups. That is not to say that these other entities 
are uninteresting - but they are not what constitutes the IETF. 


Quality: In this context, the ability to express ideas with enough 
clarity that they can be understood in the same way by all people 
building systems to conform to them, and the ability (and 
willingness) to describe the properties of the system well enough 
to understand important consequences of its design, and to ensure 
that those consequences are beneficial to the Internet as a whole. 
It also means that the specifications are designed with adherence 
to sound network engineering principles, so that use for its 
intended purpose is likely to be effective and not harmful to the 
Internet as a whole. 


Relevant: In this context, useful to some group of people who have to 
make decisions that affect the Internet, including, but not 
limited to, hardware and software implementors, network builders, 
network operators, and users of the Internet. Note that it does 


not mean "correct" or "positive" - a report of an experiment that 
failed, or a specification that clearly says why you should not 
use it in a given situation, can be highly relevant - for deciding 


what NOT to do. A part of being relevant is being timely - very 
often, documents delivered a year after core decisions have been 
taken are far less useful than documents that are available to the 
decision-makers at decision time. 


The Need for a Mission Statement 


The IETF has to make decisions. And in some cases, people acting on 
behalf of the IETF have to make decisions without consulting the 
entire IETF first. 


There are many reasons for this, including the near-impossibility of 
getting an informed consensus opinion on a complex subject out of a 
community of several thousand people in a short time. 


Having a defined mission is one of the steps we can take in order to 
evaluate alternatives: Does this help or hinder the mission, or is it 
orthogonal to it? If there are limited resources, are there things 
that they could be invested in that help the mission better? 
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(Another step is to choose leaders that we trust to exercise their 
good judgement and do the right thing. But we’re already trying to 
do that.) 


4. Issues with Scoping the IETF’s Mission 
4.1. The Scope of the Internet 


A very difficult issue in discussing the IETF’s mission has been the 
scope of the term "for the Internet". The Internet is used for many 
things, many of which the IETF community has neither interest nor 
competence in making standards for. 


The Internet isn’t value-neutral, and neither is the IETF. We want 
the Internet to be useful for communities that share our commitment 
to openness and fairness. We embrace technical concepts such as 
decentralized control, edge-user empowerment and sharing of 
resources, because those concepts resonate with the core values of 
the IETF community. These concepts have little to do with the 
technology that’s possible, and much to do with the technology that 
we choose to create. 


At the same time, it is clear that many of the IETF-defined 
technologies are useful not only for the Internet, but also for 
networks that have no direct relation to the Internet itself. 


In attempting to resolve the question of the IETF’s scope, perhaps 
the fairest balance is struck by this formulation: "protocols and 
practices for which secure and scalable implementations are expected 
to have wide deployment and interoperation on the Internet, or to 
form part of the infrastructure of the Internet." 


In addition to this constraint, we are also constrained by the 
principle of competence: Where we do not have, and cannot gather, the 
competence needed to make technically sound standards, we should not 
attempt to take the leadership. 


4.2. The Balance Between Research, Invention and Adoption 


The IETF has traditionally been a community for experimentation with 
things that are not fully understood, standardization of protocols 
for which some understanding has been reached, and publication of 
(and refinement of) protocols originally specified outside the IETF 
process. 
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All of these activities have in common that they produce documents - 
but the documents should be judged by very different criteria when 
the time to publish comes around, and it’s not uncommon to see people 
confused about what documents are in which category. 


In deciding whether or not these activities should be done within the 
IETF, one should not chiefly look at the type of activity, but the 
potential benefit to the Internet - an experiment that yields 
information about the fact that an approach is not viable might be of 
greater benefit to the Internet than publishing a standard that is 
technically competent, but only useful in a few special cases. 


For research of an essentially unbounded nature, with unknown 
probability of success, it may be more relevant to charter a research 
group than a standards group. For activities with a bounded scope - 
such as specifying several alternative protocols to the point where 
experiments can identify the better one for standardization - the 
IETF’s working group mechanism may be an appropriate tool. 


4.3. The Balance Between Mission and Procedures 


The mission is intended to state what the IETF is trying to achieve. 
There are many methods that can be chosen to achieve these outcomes - 
for instance, the appeals procedure is defined so that we can detect 
cases where our fundamental principles of technical competence and 
open process has been violated; it is not itself a fundamental value. 


Similarly, the question of what body in the IETF declares that a 
document is ready for publication is entirely outside the mission 
statement; we can imagine changing that without in any way impacting 
what the IETF mission is - even though it may significantly impact 
the ability to achieve that mission. 


4.4. The Reach of the Internet 


The Internet is a global phenomenon. The people interested in its 
evolution are from every culture under the sun and from all walks of 
life. The IETF puts its emphasis on technical competence, rough 
consensus and individual participation, and needs to be open to 
competent input from any source. The IETF uses the English language 
for its work is because of its utility for working in a global 
context. 
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4.5. Protocol Ownership 


A problem akin to the problem of deciding on the area of the IETF’s 
competence arises when a protocol that is clearly in the IETF’s scope 
is used both on and off the Internet - the premier example is of 
course the Internet Protocol itself. 


Sometimes the IETF defines standards that ultimately see the most use 
outside the global Internet. The IETF, having defined the standard, 
will continue to provide the necessary administration of that 
protocol. 


Sometimes the IETF leverages standards that are defined and 
maintained by other organizations; we continue to work with those 
organizations on their standards and do not attempt to take them 
over. 


5. Security Considerations 


Considering security is one of the core principles of sound network 
engineering for the Internet. Apart from that, it’s not relevant to 
this memo. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2004). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the IETF’s procedures with respect to rights in IETF Documents can 
be found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at ietf- 
ipr@ietf.org. 
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